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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2002). All Rights Reserved. 
Abstract 


This document describes an option for negotiating the use of robust 
header compression (ROHC) on IP datagrams transmitted over the 
Point-to-Point Protocol (PPP). It defines extensions to the PPP 
Control Protocols for IPv4 and IPv6. 


1. Introduction 


Robust Header Compression (ROHC) as defined in [RFC3095] may be used 
for compression of both IPv4 and IPv6 datagrams or packets 
encapsulated with multiple IP headers. The initial version of ROHC 
focuses on compression of the packet headers in RTP streams, while 
supporting compression of other UDP flows; however, it also defines a 
framework into which further header compression mechanisms can be 
plugged as new profiles. Planned additions to the set of profiles 
supported by ROHC will be capable of compressing TCP transport 
protocol headers as well. 


In order to establish compression of IP datagrams sent over a PPP 
link each end of the link must agree on a set of configuration 
parameters for the compression. The process of negotiating link 
parameters for network layer protocols is handled in PPP by a family 
of network control protocols (NCPs). Since there are separate NCPs 
for IPv4 and IPv6, this document defines configuration options to be 
used in both NCPs to negotiate parameters for the compression scheme. 
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ROHC does not require that the link layer be able to indicate the 
types of datagrams carried in the link layer frames. However, there 
are two basic types of ROHC headers defined in the ROHC framework: 
small-CID headers (zero or one bytes are used to identify the 
compression context) and large-CID headers (one or two bytes are used 
for this purpose). To keep the PPP packets self-describing, in this 
document two new types for the PPP Data Link Layer Protocol Field are 
defined, one for small-CID ROHC packets and one for large-CID ROHC 
packets. (This also avoids a problem that would occur if PPP were to 
negotiate which of the formats to use in each of IPCP and IPV6CP and 
the two negotiation processes were to arrive at different results.) 

A PPP ROHC sender may send packets in either small-CID or large-CID 
format at any time, i.e., the LARGE_CIDS parameter from [RFC3095] is 
not used. Any PPP ROHC receiver MUST be able to process both small- 
CID and large-CID ROHC packets, therefore no negotiation of this 
function is required. 


ROHC assumes that the link layer delivers packets in sequence. PPP 
normally does not reorder packets. When using reordering mechanisms 
such as multiclass multilink PPP [RFC2686], care must be taken so 
that packets that share the same compression context are not 
reordered. (Note that in certain cases, reordering may be acceptable 
to ROHC, such as within a sequence of packets that all do not change 
the decompression context.) 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 


2. Configuration Option 


This document specifies a new compression protocol value for the IPCP 
IP-Compression-Protocol option as specified in [RFC1332]. The new 
value and the associated option format are described in section 2.1. 


The option format is structured to allow future extensions to the 
ROHC scheme. 


It may be worth repeating [RFC1332], section 4: "The IP-Compression- 
Protocol Configuration Option is used to indicate the ability to 
receive compressed packets. Each end of the link must separately 
request this option if bi-directional compression is desired." I.e., 
the option describes the capabilities of the decompressor (receiving 
side) of the peer that sends the Configure-Request. 


Bormann Standards Track [Page 2] 


RFC 3241 ROHC over PPP April 2002 


NOTE: The specification of link and network layer parameter 
negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not 
prohibit multiple instances of one configuration option but states 
that the specification of a configuration option must explicitly 
allow multiple instances. From the current specification of the 
IPCP IP-Compression-Protocol configuration option [RFC1332] one 
can infer that it can only be used to select a single compression 
protocol at any time. 


This was appropriate at a time when only one header compression 
scheme existed. With the advent of IP header compression 
[RFC2507, RFC2509], this did not really change, as RFC 2507 
essentially superseded RFC 1144. However, with ROHC, it may now 
very well be desirable to use RFC 2507 TCP compression in 
conjunction with RFC 3095 RIP/UDP compression. 


The present document now updates RFC 1332 by explicitly allowing the 
sending of multiple instances of the IP-Compression-Protocol 
configuration option, each with a different value for IP- 
Compression-Protocol. Each type of compression protocol may 
independently establish its own parameters. 


This change is believed to not cause significant harm in existing PPP 
implementations, as they would most likely Configure-Nak or 
Configure-Reject the duplicate option, or simply happen to accept the 
one option they understand. To aid interoperability, the peer 
implementing the present specification SHOULD react to a Configure- 
Nak or Configure-Reject by reducing the number of options offered to 
one. 


2.1. Configuration Option Format 
Both the network control protocol for IPv4, IPCP [RFC1332] and the 
IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header 
Compression parameters for their respective protocols. The format of 
the configuration option is the same for both IPCP and IPVECP. 
Description 
This NCP configuration option is used to negotiate parameters for 


Robust Header Compression. The option format is summarized below. 
The fields are transmitted from left to right. 
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Figure 1: Robust Header Compression (ROHC) Option 


0 1 2 3 
O1.2:3-45 6789012345 67389 012.345 67.8.9 01 


+-+-4+-+-+-4- 44-44-4444 4444444444444 
| Type | Length | IP-Compression-Protocol 
+-+-4+-+-+-4- 44-44-4444 4444444444444 
| MAX_CID | MRRU | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| MAX_HEADER | suboptions... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 

2 
Length 

>= 10 


The length may be increased if the presence of additional 
parameters is indicated by additional suboptions. 


IP-Compression-Protocol 
0003 (hex) 


MAX_CID 
The MAX_CID field is two octets and indicates the maximum value of 
a context identifier. 


Suggested value: 15 


MAX_CID must be at least 0 and at most 16383 (The value 0 implies 
having one context). 


MRRU 
The MRRU field is two octets and indicates the maximum 
reconstructed reception unit (see [RFC3095], section 5.1.1). 


Suggested value: 0 


MAX _ HEADER 
The largest header size in octets that may be compressed. 


Suggested value: 168 octets 
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The value of MAX_HEADER should be large enough so that at least 
the outer network layer header can be compressed. To increase 
compression efficiency MAX_HEADER should be set to a value large 
enough to cover common combinations of network and transport layer 
headers. 


NOTE: The four ROHC profiles defined in RFC 3095 do not provide 
for a MAX_HEADER parameter. The parameter MAX_HEADER defined by 
this document is therefore without consequence in these profiles. 
Other profiles (e.g., ones based on RFC 2507) can make use of the 
parameter by explicitly referencing it. 


suboptions 
The suboptions field consists of zero or more suboptions. Each 
suboption consists of a type field, a length field and zero or 
more parameter octets, as defined by the suboption type. The 


value of the length field indicates the length of the suboption in 
its entirety, including the lengths of the type and length fields. 


Figure 2: Suboption 
0 1 2 
OT 2: 342 568 G0" 1.2 3) 456 7-82 9) 02T 263 
44444444444 44444444444 
| Type | Length | Parameters... 
44444444444 444444444444 


2.2. PROFILES Suboption 


The set of profiles to be enabled is subject to negotiation. Most 
initial implementations of ROHC implement profiles 0x0000 to 0x0003. 
This option MUST be supplied. 


Description 
Define the set of profiles supported by the decompressor. 
Figure 3: PROFILES suboption 
0 1 2 
Od 2-3 4S: 468.970. 3.2.34 5.067829 00 1 2° 3 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length | Profiles... 
44-44-4444 44-44-4444 4444444 


Type 
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Ir 


3. 


Length 
2n+2 


Value 
n octet-pairs in ascending order, each octet-pair specifying a 
ROHC profile supported. 


Multiple Network Control Protocols 


The ROHC protocol is able to compress both IPv6 and IPv4 datagrams. 
Both IPCP and IPV6CP are able to negotiate option parameter values 
for ROHC. The ROHC capability negotiated as a whole applies to the 
compression of packets where the outer header is an IPv4 header and 
an IPv6 header, respectively; e.g., an outer IPv6 header MUST NOT be 
sent if the ROHC IP-Compression-Protocol option was not negotiated 
for IPV6CP. 


Offering a specific ROHC capability in a Configure-Request in either 
IPCP or IPV6CP indicates that the capability is provided for the 
entire ROHC channel formed by the PPP link. When the option has been 
negotiated with different values in IPCP and IPV6CP, the result is 
that the set of parameter values for the entire ROHC channel is the 
logical union of the two values, i.e., the maximum for MAX_CID, MRRU 
or MAX_HEADER, and the logical union of the suboptions. For the 
PROFILES suboption, the logical union is the union of the two sets of 
profiles. The unified values are kept as valid parameter values for 
the ROHC channel even when either of the NCPs is taken down. 


Note that each new suboption for this option must define the meaning 
of "logical union", if the concept applies. 


1. Sharing Context Identifier Space 


For the compression and decompression of IPv4 and IPv6 datagram 
headers, the context identifier space is shared. While the parameter 
values are independently negotiated, sharing the context identifier 
spaces becomes more complex when the parameter values differ. Since 
the compressed packets share context identifier space, the 
compression engine must allocate context identifiers out of a common 
pool; for compressed packets, the decompressor has to examine the 
context state to determine what parameters to use for decompression. 


In particular, the context identifier space is shared between ROHC 
small-CID packets and ROHC large-CID packets. From the point of view 
of the ROHC framework, the PPP NCP instances for IPCP and IPV6CP 
together constitute exactly one ROHC channel; its feedback is 
destined for the ROHC channel defined by the NCP instances for IPCP 
and IPV6CP in the reverse direction on the same PPP link. 
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In particular, this means that taking down either of the NCPs while 
the other is still open means that the contexts of the channel stay 
active. To avoid race conditions, the same is true if both NCPs are 
taken down and then one or more is reopened. Taking down LCP 
destroys the channel, however; reopening LCP and then one or more of 
IPCP and IPV6CP restarts ROHC with all contexts in no-context state. 


4. Demultiplexing of Datagrams 


The ROHC specification [RFC3095] defines a single header format for 
all different types of compressed headers, with a variant for small 
CIDs and a variant for large CIDs. Two PPP Data Link Layer Protocol 
Field values are specified below. 


ROHC small-CIDs 


The frame contains a ROHC packet with small CIDs as defined in 
[RFC3095]. 


Value: 0003 (hex) 
ROHC large-CIDs 


The frame contains a ROHC packet with large CIDs as defined in 
[RFC3095]. 


Value: 0005 (hex) 


Note that this implies that all CIDs within one ROHC packet MUST be 
of the same size as indicated by the Data Link Layer Protocol field, 
either small or large. In particular, embedded feedback MUST have a 
CID of the same size as indicated by the Protocol field value. For 
piggybacking feedback, a compressor must be able to control the 
feedback CID size used by the associated decompressor, ensure that 
all CIDs are of the same size, and indicate this size with the 
appropriate Protocol Field value. 


To make CID interpretation unambiguous when ROHC segmentation is 
used, all packets that contribute to a segment MUST be sent with the 
same Data Link Layer Protocol Field value, either 0003 or 0005, which 
then also applies to the CID size in the reconstructed unit. A unit 
reconstructed out of packets with Protocol field values that differ 
MUST be discarded. 
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5. ROHC Usage Considerations 


Certain considerations are required for any ROHC-over-X protocol. 
This section describes how some of these are handled for ROHC over 
PPP. 


5.1. Uncompressed profile 


There is no need for the ROHC uncompressed profile in ROHC over PPP, 
as uncompressed packets can always be sent using the PPP protocol 
demultiplexing method. Therefore, no consideration was given to 
locking down one of the context numbers for the uncompressed profile 
(see [RFC3095] section 5.1.2). Note, however, that according to the 
ROHC specification, profile 0x0000 must not be rejected [RFC3095], so 
it MUST be implemented by all receivers. 


5.2. Parameter selection 


For each of the ROHC channel parameters MAX_CID and MRRU, the value 
is the maximum of the respective values negotiated for the IPCP and 
IPv6CP instances, if any. The ROHC channel parameter FEEDBACK_FOR is 
set implicitly to the reverse direction on the same PPP link (see 
"Sharing Context Identifier Space" above). The ROHC channel 
parameter LARGE_CIDS is not used, instead the PPP protocol ID on the 
packet is used (see "Demultiplexing of Datagrams" above). 


A number of parameters for ROHC must be set correctly for good 
compression on a specific link. E.g., the parameters k_1, n_l, k_2, 
n_2 in section 5.3.2.2.3 of [RFC3095] need to be set based on the 
error characteristics of the underlying links. As PPP links are 
usually run with a strong error detection scheme [RFC1662], k_1 = n_1 

k_2 n_2 1 is usually a good set of values. (Note that in any 
case k values need to be set low enough relative to n values to allow 
for the limited ability of the CRC to detect errors, i.e., the CRC 
will succeed for about 1/8 of the packets even in case of context 
damage, so k/n should be significantly less than 7/8.) 


6. Security Considerations 


Negotiation of the option defined here imposes no additional security 
considerations beyond those that otherwise apply to PPP [RFC1661]. 


The security considerations of ROHC [RFC3095] apply. 
The use of header compression can, in rare cases, cause the 


misdelivery of packets. If necessary, confidentiality of packet 
contents should be assured by encryption. 
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Encryption applied at the IP layer (e.g., using IPSEC mechanisms) 
precludes header compression of the encrypted headers, though 
compression of the outer IP header and authentication/security 
headers is still possible as described in [RFC3095]. For RIP 
packets, full header compression is possible if the RTP payload is 
encrypted by itself without encrypting the UDP or RTP headers, as 
described in [RFC1889]. This method is appropriate when the UDP and 
RTP header information need not be kept confidential. 


7. IANA considerations 


The ROHC suboption identifier is a non-negative integer. Following 
the policies outlined in [RFC2434], the IANA policy for assigning new 
values for the suboption identifier shall be Specification Required: 
values and their meanings must be documented in an RFC or in some 
other permanent and readily available reference, in sufficient detail 
that interoperability between independent implementations is 
possible. The range 0 to 127 is reserved for IETF standard-track 
specifications; the range 128 to 254 is available for other 
specifications that meet this requirement (such as Informational 
RFCs). The value 255 is reserved for future extensibility of the 
present specification. 


The following suboption identifiers are already allocated: 


Suboption Document Usage 
identifier 
1 RFC3241 Profiles 


The RFC 3006 compressibility hint [RFC3006] for ROHC is 0x0003pppp, 
where Oxpppp is the profile assumed. 


(Note that the PPP protocol identifier values 0003 and 0005 were 
taken from a previously reserved space that exhibits inefficient 
transparency in the presence of asynchronous control character 
escaping, as it is considered rather unlikely that ROHC will be used 
over links with highly populated ACCMs.) 
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11. Full Copyright Statement 
Copyright (C) The Internet Society (2002). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Bormann Standards Track [Page 12] 


